
# Eroom 작업실 문제점들

1. 증거문서 폴더 / 고객상담문서 폴더
- 여러개 파일을 한번에 업로드 하는 것이 불가능
- 문서가 많이 업로드 되었을 때, 마우스 스크롤 작동 안함, 오른편에 스크롤 바도 없음

2. 자동진행 표시를 하지 않고 진행했는데도 자동진행이 됨

3. Eroom 작업실에 run-time 표시가 없음


[수정요청]
2. 진행률 bar는 세부 작업 진행되면서 %와 bar progress로 동시에 표현되도록. 

---------------------------------------------------
Agent 자동실행

6:58 55초부터 시작


마무리까지 총 20분 예상 (by 7:18, 55)

7:14분 완성

[평가]
- 청구권식별 엉망 
 - Why? 도저히 알 수 없음
  - 재시도 후에도 결과X → Stage 2 GPT-5.4 high로 교체/테스트

---------------------------------------------------

1단계
7:17시작 (예상 7:23까지) --> 예상 확인

자동진행되어버려서 7:37까지 기다릴 것

[평가]
- 청구권식별 엉망이라서 도중에 STOP

---------------------------------------------------

Dev 에서 stage별로 쪼개서 다시 진행

[문제점]
- Dev 화면에서도 [확인, 다음 작업 진행] 등의 option 표시가 다 사라짐
- 결과가 이상하여 stage 1에서 LLM 추론을 high로 조정

## Stage 1
Run-time: 4min 56secs
Cost: $1.20 (아무래도 이전 단계에서 사용했던 일부 cache hit 의심)

## Stage 2-1
Run-time: 3min 41secs
Cost: $3.45
[특이사항]
- C가 이상하게 오래걸림 --> 생성되고도 stage 지속 (30초 이상) --> 체크할 것


## Stage 2-2
Run-time:
Cost: $

## Stage 2-3
Run-time:
Cost:

## Stage 3
Run-time:
Cost:

## Stage 4
Run-time:
Cost:

## Stage 5
Run-time:
Cost:




----------------------------------------------





Stage 2 - Task_B

[점검할 항목들] 
<succession_resolution_prepass_rules>

<generic_kinship_downgrade_rules>

<plaintiff_standing_resolution_rules>

<succession_emission_gate>

<benefit_recipient_and_time_split_rules>

[미식별청구권]
4. {"claim_title":"부당이득반환 청구","plaintiffs":["강용원"],"defendants":["이문호"],"claim_statement":"원고 강용원은 피고 이문호를 상대로 부당이득반환 청구를 할 수 있다."}

## 이문호(혹은 박성희)상대 부당이득반환청구 누락된 이유 (과거분석)
성수동 가지(branch)에서 구조화된 fact는 주로 `경매 낙찰(F-027)`, `근저당권 설정(F-028)`, `인도명령에 의한 대지 인도(F-029)`, `건물 신축(F-031)`, `대지 임대(F-032)`, `건물 매매(F-033)`입니다. 즉, 사건행위는 풍부하지만, “무권원 사용수익으로 이득을 취하였다”, “차임 상당 이득을 반환해야 한다”, “법률상 원인 없는 이득”이라는 형식의 **직접적인 이득 귀속 fact**는 구조화되어 있지 않습니다. 반면 박광윤에 대해서는 `유치권 행사하며 임대`, `계속 점유`, `유치권 소멸청구 통지` 등 점유·사용·이득과 연결되는 fact가 비교적 직접적으로 정리되어 있어서 `부당이득반환청구`가 더 쉽게 식별되었습니다. 이는 출력 구조에 기초한 제 추론이지만, 상당한 설명력을 가집니다.

이문호에 대해서는 구조화 fact가 `경매낙찰 → 소유권이전등기 → 인도명령 → 건물신축 → 후속 임대/매도`로 잡혀 있습니다. 그런데 pipeline은 이 연쇄를 “경매 효력 문제로 인한 소유권이전등기말소”, “후속 근저당권설정등기말소”, “신축 건물 철거 및 토지인도”로 잘게 나누는 데 유리한 구조를 가지고 있었습니다. 반면 `부당이득반환`은 “무권원 이득 귀속”이라는 한 단계 높은 법률구성을 필요로 하는데, 그를 직접 지시하는 fact anchor가 약했습니다. 그래서 이문호 branch에서는 `C-007`, `C-008`, `C-009`가 남고, `부당이득반환청구`는 생기지 않은 것입니다. `claims_identified.json` 자체도 이 세 청구를 확정이 아니라 후보로만 남기고 있습니다.

Stage 1에서 부분적으로 오염된 structured fact/view를 전제로, source_fact_id로 명시적으로 앵커링 가능한 사건행위에 가장 가까운 주문형 청구를 먼저 산출하도록 설계되어 있다**는 점입니다. 그 결과 성수동 branch에서는 `부당이득반환청구` 같은 종합적 법률구성은 약해지고, `소유권이전등기말소`, `근저당권설정등기말소`, `건물철거 및 토지인도`, `건물퇴거` 같은 직접 사건행위 대응형 청구가 상대적으로 쉽게 선택된 것



--------------------------------------------------------------------

[작업]

1. 식별청구권 불일치 원인 분석
- GPT 프로젝트 신설 
 - 전제조건과 결과물 투입하여 원인 분석
  - 과거 원인 분석과 비교

2. Stage 2 군더더기 청구권 배제 능력 키우기
- 강vs박 문제를 해결할 수 있는 anchor 재설정
 - Stage 2 - Task_B 프롬프트 개선
  - 인간변호사 사고 방식 최대한 반영

3. Stage 1 프롬프트 개선
- Stage 1에서 최고 품질의 결과가 전제되어야 함
 - 그래서 Gemini가 
  1. 프롬프트가 제시하는 작업을 정확하게 따라하도록, 
  2. 최대한의 추론 능력을 발휘하여 최고 수준의 변호사의 지적 작업 능력을 발휘하도록
프롬프트를 개선하기

4. 

--------------------------------------------------------------------


나는 현재 사용자(user)가 변호사인 a full vertical legal AI Agent를 개발 중이다. 이 에이전트는 대한민국 민사소송에서 원고를 대리하는 변호사가 사용자인 경우를 다루는 법률 인공지능 에이전트다. 사용자가 고객상담문서(client_meeting.md)와 모든 증거문서(서증)들을 정보화한 JSON 문서(evidence_all.json)을 업로드하면 에이전트는 1단계부터 5단계까지 작업을 순차적으로 진행하여 최종적으로 소장(complaint)을 생성한다. 사용자가 고객상담문서(client_meeting.md)와 모든 증거문서(서증)들을 정보화한 JSON 문서(evidence_all.json)을 이미 업로드했음을 가정한다. 

Stage 1에서 에이전트는 현재 다루고 있는 사건의 개요를 상세하게 파악한다. 에이전트는 `Stage_1.yaml`을 실행하여 결과물을 생성한다. 생성한 결과물들은 각각 
- actio_case_signals.json
- BO.json
- client_goal.json
- evidence_actio_support.json
- evidence_event_candidates.json
- evidence_indexed.json
- fact_actio_support.json
- Fact_Ledger_base.json
- stage1.html 들인데, 
`stage1.html`을 제외한 나머지 모두를 하나의 단일 파일 `stage_1_results_8pm.xml`에 제시하였다. 

Stage 2에서 에이전트는 1단계 결과물들을 입력받아 소송 청구권들을 식별하고 그 청구권들의 사건 종류를 결정한다. 에이전트는 `Stage_2_1.yml`을 실행하여 결과물을 생성하며, 생성한 결과물들은 각각 
- claim_identification_view.json
- claims_identified_case_type.json
- claims_identified.json 이다. 
이 세가지 결과물 파일을 하나의 단일 파일 `stage_2_results_8pm.xml`에 제시하였다.

claims_identified.json은 현재 사건에 대해서 에이전트가 식별한 청구권들을 나열하고 있다. 에이전트가 식별한 청구권들과 20년 이상 경력을 보유한 대한민국 최고 수준의 변호사가 식별하여 제시한 청구권 목록 사이에 차이가 존재한다. 인간 변호사가 식별하여 제시한 청구권 목록은 `인간변호사.txt`에 제시되어 있다. 

`claims_identified.json`과 `인간변호사.txt`를 비교한 내용은 다음과 같다. 

<비교분석>
1. 인간변호사가 식별한 청구권들 중 4번 청구권은 에이전트가 식별하지 못했다. 
- 인간변호사가 식별한 4번 청구권 내용은 
**4. {"claim_title":"부당이득반환 청구","plaintiffs":["강용원"],"defendants":["이문호"],"claim_statement":"원고 강용원은 피고 이문호를 상대로 부당이득반환 청구를 할 수 있다."}**
인데, 에이전트는 이 청구권을 식별하는데 실패했다. 

2. 에이전트가 식별한 청구권 중 C-003, C-005는 인간변호사가 제시한 청구권 목록에 존재하지 않는다. 
- C-003, C-005는 원고 '강용원' vs 피고 '박광윤'을 다룬다. 그런데 이 구조는 사실 원고 '양정숙' vs 피고 '박광윤'에 해당하는 C-004, C-006에서 정상적으로 다루어진다. 
- 평택시 빌라 관련한 청구권 식별에서 인간 변호사는 '양정숙'을 유일한 원고로 취급하였다. 에이전트는 '강용원' 역시 적법한 평택시 빌라 상속권리자로 판단하여 C-003, C-005를 제시하였다. 하지만, 대한민국 민사소송의 실무에서는 이 때, '강용원'을 대체적으로 제외하고 '양정숙'만을 원고로 파악한다. 
</비교분석>

위의 1, 2 결과가 발생한 원인을 분석하고자 한다. 

다음의 <조건>을 준수하여, 원인을 분석하라. 

<조건>
1. 20년 이상 경력을 지닌 대한민국 최고 수준의 변호사 및 세계적인 수준의 인공지능 아키텍트 전문가의 관점에서 원인을 분석하라. 
2. Stage_1.yml을 실행하여 얻은 stage_1_results_8pm.xml과 Stage_2_1.yml을 실행하여 얻은 stage_2_results_8pm.xml을 하나도 빠짐없이 정교하게 분석하여 Stage 1에서 Stage 2로 이어지는 과정을 매우 정교하게 해부하듯 분석하여 위에서 제시한 <비교분석> 내용이 발생한 원인을 분석하라. 
3. 분석한 원인은 `claims_inconsistency_reason.md` 파일명으로 마크다운 문서로 작성하고 생성하라. 
</조건>


------------------------------------------------------------------

관련 산출물과 파이프라인 정의를 모두 대조해 원인 사슬을 재구성하겠습니다. 우선 Stage 1/2 정의, 두 XML 결과물, 상담일지, 인간 변호사 목록을 함께 해부해 누락·과잉 식별이 어느 노드에서 발생했는지 추적하겠습니다.
지금까지 드러난 핵심은 두 갈래입니다. 평택시 빌라의 과잉 원고 식별은 상속·원고적격 해소가 실패한 상태에서 공동행동·가족관계 신호가 다시 원고 후보를 넓힌 결과로 보이고, 성수동 대지의 부당이득 누락은 “이문호 시기”와 “박성희 시기”의 사용수익 time-slice가 분리되지 않은 정황이 강합니다.

분석 문서를 생성했습니다.

[claims_inconsistency_reason.md](sandbox:/mnt/data/claims_inconsistency_reason.md)

문서에는 Stage 1의 grounding 오류, Stage 1↔Stage 2 스키마 불일치, Stage 2의 succession/time-slice 복원 실패, 그리고 최종 emission veto 부재를 분리해 정리했습니다. 특히 평택시 빌라 부분은, 자녀 전부가 상속을 포기한 경우 배우자와 직계존속이 공동상속인이 될 수 있다는 공식 법리를 고려하면 강용원 포함이 전적으로 허구라기보다 complaint drafting policy와 법률 ontology가 충돌한 측면도 있음을 별도로 구분해 두었습니다.


--------------------------------------------------------------------

`claims_inconsistency_reason.md`에 제시된 **8. 가장 중요한 개선안**에 제시된 개선 방안들을 적용 시, stage 1에서 stage 2로 넘어가는 과정에서 stage 1의 Tasks, stage 2의 Tasks들을 각각 어떻게 개선할지를 tasks 순서대로 제시하라. 


===================================================================================

정리하면, 실제 구현 우선순위는 다음 네 묶음이다. 첫째, Stage 1 Task_B1 출력 shape와 Stage 2 Task_A unwrap을 즉시 맞춘다. 둘째, Stage 1 Task_A·B2·C에서 상속 bundle, mixed-contract component, valuation row, state interval을 강제 생성한다. 셋째, Stage 2 Task_A에서 specialized succession linker와 slice builder를 넣는다. 넷째, Stage 2 Task_B에 deterministic veto를 넣어 unresolved succession과 plaintiff duplication을 차단한다. 이 네 묶음이 들어가야 이번 불일치의 두 축, 즉 이문호 부당이득 누락과 강용원 v. 박광윤 과잉 식별이 동시에 해소된다.

===================================================================================


아래 작업을 순서대로 실행하라. 
1. 지금 위에서 제시된 개선 방안들을 정확히 파악한다.
2. **첫째, Stage 1 Task_B1 출력 shape와 Stage 2 Task_A unwrap을 즉시 맞춘다.**를 따라서, 앞에서 제시된 개선 방안들 중 Stage 1 Task_B1 개선 방안과 Stage 2 Task_A 개선 방안을 `Stage_1.yaml`의 Task_B1과 Stage_2_1.yml의 Task_A 프롬프트에 정확히 반영하여 두 프롬프트를 재작성한다.
3. 재작성한 Stage 1 yaml 파일을 `Stage_1_B1.yaml`로, 재작성한 Stage 2 yaml 파일을 `Stage_2_1_A.yml`로 생성한다. 

--------------------------------------------------------------------

Stage_2_1.yml

아래 작업을 순서대로 실행하라. 

**둘째, Stage 1 Task_A·B2·C에서 상속 bundle, mixed-contract component, valuation row, state interval을 강제 생성한다.**를 따라서
1. 앞에서 제시된 Stage 1 Task_A·B2·C의 개선 방안을 정확히 반영하여, `Stage_1.yaml`의 Task_A, Task_B2, Task_C 프롬프트를 재작성한다. 
2. 재작성한 프롬프트들을 `Stage_1_A_B2_C.yaml`로 생성한다. 


--------------------------------------------------------------------

아래 작업을 순서대로 실행하라. 

**셋째, Stage 2 Task_A에서 specialized succession linker와 slice builder를 넣는다.**를 따라서, 
1. `Stage_2_1_A.yml`에 제시된 Task_A 프롬프트에 `specialized succession linker와 slice builder를 넣는` 작업을 앞에서 제시된 개선 방안을 정확히 반영하여 수행하여, 
2. `Stage_2_1_A.yml`의 Task_A 프롬프트를 다시 작성하고, 
3. 그것을 `Stage_2_1_A_update.yml`로 생성하라. 

--------------------------------------------------------------------

아래 작업을 순서대로 실행하라. 

**넷째, Stage 2 Task_B에 deterministic veto를 넣어 unresolved succession과 plaintiff duplication을 차단한다.**를 따라서,
1. `Stage_2_1.yml`에 제시된 Task_B 프롬프트에 앞에서 제시된 "Task_B에 deterministic veto를 넣어 unresolved succession과 plaintiff duplication을 차단"하는 개선 방안을 정확히 적용하여 프롬프트를 개선하고,
2. Task_B 프롬프트를 전체 재작성하여, 
3. `Stage_2_1_B.yml`로 생성하라. 


===================================================================================

[Optional Optimization]

5. Task_B3 (`evidence_actio_support.json`)
이 task는 본 불일치의 직접 원인은 아니지만, 개선 시에는 “문서별 sparse support”를 사해행위취소 전용으로만 보지 말고, Stage 2 claim identification이 재사용할 수 있는 시점별 가치·부담 snapshot도 더 세밀하게 남기는 쪽이 좋다. 특히 valuation row, encumbrance row, beneficiary gain snapshot을 first item만 남기고 버리지 않도록 강제하는 현재 mission을 더 확장해, 사용이익 산정이나 현재 가치 산정에 도움이 되는 support row를 구간별로 보존하면 좋다. 이 부분은 직접적인 결함 로그보다는 파이프라인 정합성에 기초한 설계 추론의 성격이 강하다.

6. Task_D1 (`Fact_Ledger_base.json`)
이 task는 `1 BO = 1 Fact`와 slot-safe merge를 지키도록 설계되어 있으므로, 개선 방향도 명확하다. 첫째, BO에서 도입한 interval 필드를 fact에도 그대로 내려야 한다. 둘째, `legal_calculation_object`만 병합할 것이 아니라, `standing_context_seed`, `succession_bundle_ref`, `property_cluster_id`, `state_interval_meta` 같은 claim-identification용 optional field를 두어 Stage 2 Task_A가 다시 역추론하지 않게 해야 한다. 셋째, later snapshot이 prior fact를 오염시키지 않도록 현재의 slot-safe merge 규칙을 더 엄격히 하고, safe slot이 없으면 무조건 생략하도록 해야 한다.

7. Task_D2 (`fact_actio_support.json`)
이 task도 직접 원인 노드는 아니지만, BO별 support normalization 단계에서 `preserved_claim_candidates`나 linked support를 하나의 단일 snapshot으로 압축하지 않도록 더 명확히 해야 한다. 특히 Stage 2 Task_A가 이 파일을 읽어 case signal과 support를 결합하므로, 향후에는 optional field로 `support_slice_refs`, `standing_relevance_flags`, `interval_relevance_flags`를 두어 Stage 2 Task_B가 “이 support가 어느 plaintiff/slice와 연결되는지”를 더 쉽게 판단하게 만들 수 있다. 이 역시 설계 추론의 비중이 다소 크지만, D2를 그대로 두면 앞단에서 만든 구간·standing 정보가 Stage 2로 충분히 전달되지 않는다.

8. Task_Display
이 task는 법리 판단 엔진이 아니라 사람 검토용이므로, 직접 원인 수정의 1순위는 아니다. 다만 실제 운영에서는 여기서 (a) 자산군별 current right holder / possessor / user / benefit holder 분리표, (b) state interval 타임라인, (c) succession bundle과 provisional/final 구분, (d) complaint plaintiff preference를 시각화해 주어야 한다. 그러면 Stage 2 진입 전에 “강용원을 소유자/final로 잘못 박은 경우”나 “이문호 state가 박성희 등장 이후에도 계속 열려 있는 경우”를 사람이 즉시 걸러낼 수 있다. 이 항목은 주로 운영 설계상의 권고다.

===================================================================================

Stage 1:
A, B1, B2, C 수정완료
  - A, B2, C -- Stage_1_A_B2_C.yaml
  - B1 -- Stage_1_B1.yaml


[Optional] -- not done
Stage_1.yaml > B3, D1, D2 업데이트 

===================================================================================

[New Test]

4/19 3:52pm

[Stage 1]
Run-time: 6min 17secs
Cost: $2.08


[Stage 2_1]
Run-time: 5min 27secs
Cost: $1.75

* 식별된 청구권 평가

NOT GOOD

===================================================================================

[New Test - 1]

Stage 1 updated + Stage 2-1 이전 버전

4/19 4:40pm

[Stage 2_1]
Run-time: 3min 20secs
Cost: 

청구권 평가
NOT Good

===================================================================================

아예 이전버전으로 재시도

Stage 1 
런타임: 5min 36secs
비용: $1.60

Stage 2
런타임: 4min 22secs
비용: $2.43
==> 청구권 분석: 2개 missing (강vs박 해결)

Stage 2 -- GPT-5.4로 재시도 
런타임: 8min 24secs
비용: $2.71 

1, 8, 11, 2, 3, 7, 6, 4, 5
missing: 9, 10 (양정숙vs박광윤 missing) -- "평택시 빌라 관련 상속인 확정 자료 보강 필요" too strong 조건


===================================================================================

테스트 조합

[Updated Stage 1] - [Updated Stage 2 -- GPT]

4/19, 5:21pm

Stage 1
런타임 5min 4secs
비용 $1.76

Stage 2
런타임 4min (아마도 cache hit)
비용 

청구권 분석
1, 2, X, 10, 8, 11, X, 9, 3, 6, 5

Missing -- 4, 7
7 --> related measure에 기입

4만 문제: --> 지속적으로 자주 등장

===================================================================================

┌──────────────────────────────┐
│                              │
│                              │
│ # 변시_Re_Test_4_19_original  │
│                              │
│                              │
└──────────────────────────────┘
4/19 
11:05pm

[Original Prompt Test]

Stage 1
런타임 5min 38secs
비용 $1.31

Stage 2
런타임 4min 14secs
비용 $2.64

[청구권 분석]

1, 강vs박, 10, 8, 11, 강vs박, 9, 2, 3, 7, 6, 5

Missing: 4

==> GPT 연구

4번 missing 이유만 분석 --> 최소한의 수정 --> update --> test
 

--------------------------------------------------------------------------

[Updated Test] w/ Gemini








[Updated Test] w/ GPT
 

















































